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The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP) 
Abstract 
This document provides clarifications and guidelines concerning the 
use of the SIPS URI scheme in the Session Initiation Protocol (SIP). 
It also makes normative changes to SIP. 
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Introduction 


The meaning and usage of the SIPS URI scheme and of Transport Layer 
Security (TLS) [RFC5246] are underspecified in SIP [RFC3261] and have 
been a source of confusion for implementers. 


This document provides clarifications and guidelines concerning the 

use of the SIPS URI scheme in the Session Initiation Protocol (SIP). 
It also makes normative changes to SIP (including both [RFC3261] and 
[RFC3608]. 


Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 


document are to be interpreted as described in [RFC2119]. 


Background 


.1. Models for Using TLS in SIP 


This section describes briefly the usage of TLS in SIP. 


.1.1. Server-Provided Certificate 


In this model, only the TLS server provides a certificate during the 
TLS handshake. This is applicable only between a user agent (UA) and 
a proxy, vhere the UA is the TLS client and the proxy is the TLS 
server, and hence the UA uses TLS to authenticate the proxy but the 
proxy does not use TLS to authenticate the UA. If the proxy needs to 
authenticate the UA, this can be achieved by SIP HTTP digest 
authentication. This directionality implies that the TLS connection 
alvays needs to be set up by the UA (e.g., during the registration 
phase). Since SIP allows for requests in both directions (e.g., an 
incoming call), the UA is expected to keep the TLS connection alive, 
and that connection is expected to be reused for both incoming and 
outgoing requests. 


This solution of having the UA always initiate and keep alive the 
connection also solves the Network Address Translation (NAT) and 
firewall problem as it ensures that responses and further requests 
will always be deliverable on the existing connection. 


[RFC5626] provides the mechanism for initiating and maintaining 
outbound connections in a standard interoperable way. 
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3.1.2. Mutual Authentication 


In this model, both the TLS client and the TLS server provide a 
certificate in the TLS handshake phase. When used between a UA and a 
proxy (or between two UAs), this implies that a UA is in possession 
Of a certificate. When sending a SIP request when there is not 
already a suitable TLS connection in place, a user agent client (UAC) 
takes on the role of TLS client in establishing a new TLS connection. 
When establishing a TLS connection for receipt of a SIP request, a 
user agent server (UAS) takes on the role of TLS server. Because in 
SIP a UA or a proxy acts both as UAC and UAS depending on if it is 
sending or receiving requests, the symmetrical nature of mutual TLS 
is very convenient. This allovs for TLS connections to be set up or 
torn dovn at vill and does not rely on keeping the TLS connection 
alive for further requests. 


Hovever, there are some significant limitations. 


The first obvious limitation is not vith mutual authentication per 
se, but vith the model vhere the underlying TCP connection can be 
established by either side, interchangeably, vhich is not possible in 
many environments. For examples, NATs and firevalls vill often allov 
TCP connections to be established in one direction only. This 
includes most residential SIP deployments, for example. Mutual 
authentication can be used in those environments, but only if the 
connection is alvays started by the same side, for example, by using 
İRFC56261 as described in Section 3.1.1. Having to rely on [RFC5626] 
in this case negates many of the advantages of mutual authentication. 


The second significant limitation is that mutual authentication 
requires both sides to exchange a certificate. This has proven to be 
impractical in many environments, in particular for SIP UAs, because 
of the difficulties of setting up a certificate infrastructure for a 
vide population of users. 


For these reasons, mutual authentication is mostly used in server-to- 
server communications (e.g., between SIP proxies, or between proxies 
and gateways or media servers), and in environments where using 
certificates on both sides is possible (e.g., high-security devices 
used vithin an enterprise). 


3.1.3. Using TLS with SIP Instead of SIPS 
Because a SIPS URI implies that requests sent to the resource 
identified by it be sent over each SIP hop over TLS, SIPS URIs are 


not suitable for "best-effort TLS": they are only suitable for "TLS- 
only" requests. This is recognized in Section 26.2.2 of [RFC3261]. 
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Users that distribute a SIPS URI as an address-of-record may elect 
to operate devices that refuse requests over insecure transports. 


If one vants to use "best-effort TLS" for SIP, one yust needs to use 
a SIP URI, and send the request over TLS. 


Using SIP over TLS is very simple. A UA opens a TLS connection and 
uses SIP URIs instead of SIPS URIs for all the header fields in a SIP 
message (From, To, Request-URI, Contact header field, Route, etc.). 
When TLS is used, the Via header field indicates TLS. 


[REC3261], Section 26.3.2.1, states: 


When a UA comes online and registers with its local administrative 
domain, it SHOULD establish a TLS connection with its registrar 
(...). Once the registration has been accepted by the registrar, 
the UA SHOULD leave this TLS connection open provided that the 
registrar also acts as the proxy server to which requests are sent 
for users in this administrative domain. The existing TLS 
connection will be reused to deliver incoming requests to the UA 
that had just completed registration. 


İRFC56261 describes how to establish and maintain a TLS connection in 
environments where it can only be initiated by the UA. 


Similarly, proxies can forward requests using TLS if they can open a 
TLS connection, even if the route set used SIP URIs instead of SIPS 
URIs. The proxies can insert Record-Route header fields using SIP 
URIs even if it uses TLS transport. [REC3261], Section 26.3.2.2, 
explains how interdomain requests can use TLS. 


Some user agents, redirect servers, and proxies might have local 
policies that enforce TLS on all connections, independently of 
whether or not SIPS is used. 


3.1.4. Usage of the transportetls URI Parameter and the TLS Via 
Parameter 


İRFC32611, Section 26.2.2 deprecated the "transportetls" URI 
transport parameter in SIPS or SIP URIs: 


Note that in the SIPS URI scheme, transport is independent of TLS, 
and thus "sips:alicefatlanta.com;transport=TCP" and 
"sips:alicefatlanta.com;transport=sctp" are both valid (although 


note that UDP is not a valid transport for SIPS). The use of 
"transportetls" has consequently been deprecated, partly because 
it vas specific to a single hop of the request. This is a change 


since RFC 2543. 
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The "tls" parameter has not been eliminated from the ABNF in 
İRFC32611, Section 25, since the parameter needs to remain in the 
ABNF for backvard compatibility in order for parsers to be able to 
process the parameter correctly. The transportetls parameter has 
never been defined in an RFC, but only in some of the Internet drafts 
between [RFC2543] and [RFC3261]. 


This specification does not make use of the transport-tls parameter. 


The reinstatement of the transportetls parameter, or an alternative 
mechanism for indicating the use of the TLS on a single hop in a URI, 
is outside the scope of this specification. 


For Via header fields, the following transport protocols are defined 
in [RFC3261]: "UDP", "TCP", "TLS", "SCTP", and in [RFC4168]: "TLS- 
SCIP". 


3.2. Detection of Hop-by-Hop Security 


The presence of a SIPS Request-URI does not necessarily indicate that 
the request vas sent securely on each hop. So hov does a UAS knov if 
SIPS vas used for the entire request path to secure the request end- 
to-end? Effectively, the UAS cannot know for sure. However, 
İRFC32611, Section 26.4.4, recommends hov a UAS can make some checks 
to validate the security. Additionally, the History-Info header 
field [RFC4244] could be inspected for detecting retargeting from SIP 
and SIPS. Retargeting from SIP to SIPS by a proxy is an issue 
because it can leave the receiver of the request vith the impression 
that the request vas delivered securely on each hop, vhile in fact, 
it vas not. 


To emphasize, all the checking can be circumvented by any proxies or 
back-to-back user agents (B2BUAs) on the path that do not follov the 
rules and recommendations of this specification and of [RFC3261]. 


Proxies can have their ovn policies regarding routing of requests to 
SIP or SIPS URIs. For example, some proxies in some environments can 
be configured to only route SIPS URIs. Some proxies can be 
configured to detect non-compliances and reject unsecure requests. 
For example, proxies could inspect Request-URIs, Path, Record-Route, 
To, From, Contact header fields, and Via header fields to enforce 
SIPS. 


IRFC32611, Section 26.4.4, explains that S/MIME can also be used by 
the originating UAC to ensure that the original form of the To header 
field is carried end-to-end. While not specifically mentioned in 
İRFC32611, Section 26.4.4, this is meant to imply that [RFC3893] 
vould be used to "tunnel" important header fields (such as To and 
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From) in an encrypted and signed S/MIME body, replicating the 
information in the SIP message, and alloving the UAS to validate the 
content of those important header fields. While this approach is 
certainly legal, a preferable approach is to use the SIP Identity 
mechanism defined in [RFC4474]. SIP Identity creates a signed 
identity digest, which includes, among other things, the Address of 
Record (AOR) of the sender (from the From header field) and the AOR 
of the original target (from the To header field). 


3.3. The Problems with the Meaning of SIPS in RFC 3261 
[RFC3261], Section 19.1, describes a SIPS URI as follows: 


A SIPS URI specifies that the resource be contacted securely. 
This means, in particular, that TLS is to be used between the UAC 
and the domain that owns the URI. From there, secure 
communications are used to reach the user, where the specific 
security mechanism depends on the policy of the domain. 


Section 26.2.2 re-iterates it, with regards to Request-URIs: 


When used as the Request-URI of a request, the SIPS schene 
signifies that each hop over which the request is forwarded, until 
the request reaches the SIP entity responsible for the domain 
portion of the Request-URI, must be secured with TLS, once it 
reaches the domain in question it is handled in accordance vith 
local security and routing policy, quite possibly using TLS for 
any last hop to a UAS. When used by the originator of a request 
(as vould be the case if they employed a SIPS URI as the address- 
of-record of the target), SIPS dictates that the entire request 
path to the target domain be so secured. 


Let”s take the classic SIP trapezoid to explain the meaning of a 


sips:b@B URI. Instead of using real domain names like example.com 
and example.net, logical names like "A" and "B" are used, for 
clarity. 
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+------- + +------- + 
| | | | 

| Proxy | məm ILS---- | Proxy | 

e v Í IB | 

| | | | 

L a + —l-—-——— + \ 
/ \ 

/ \ 
TLS Policy-based 
/ \ 

/ \ 

/ \ 
+------- + +------- + 
UAC a UAS b 
| | | | 
+------- + +------- + 
Domain A Domain B 


SIP trapezoid with last-hop exception 


According to [RFC3261], if a@A is sending a request to sips:b@B, the 
following applies: 


o TLS is required between UA a@A and Proxy A 
o TLS is required between Proxy A and Proxy B 


o TLS is required between Proxy B and UA b@B, depending on local 
policy. 


One can then wonder why TLS is mandatory between UA a@A and Proxy A 
but not between Proxy B and UA b@B. The main reason is that 
[RFC3261] was written before [RFC5626]. At that time, it was 
recognized that in many practical deployments, Proxy B might not be 
able to establish a TLS connection with UA b because only Proxy B 
would have a certificate to provide and UA b would not. Since UA b 
would be the TLS server, it would then not be able to accept the 
incoming TLS connection. The consequence is that an [RFC3261]- 
compliant UAS b, while it might not need to support TLS for incoming 
requests, will nevertheless have to support TLS for outgoing requests 
as it takes the UAC role. Contrary to what many believed 
erroneously, the last-hop exception was not created to allow for 
using a SIPS URI to address a UAS that does not support TLS: the 
last-hop exception vas an attempt to allow for incoming requests to 
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not be transported over TLS vhen a SIPS URI is used, and it does not 


apply to outgoing requests. The rationale for this vas somewhat 
flaved, and since then, [RFC5626] has provided a more satisfactory 
solution to this problem. [RFC5626] also solves the problem that if 


UA b is behind a NAT or firevall, Proxy B vould not even be able to 
establish a TCP session in the first place. 


Furthermore, consider the problem of using SIPS inside a dialog. If 
a@A sends a request to b@B using a SIPS Request-URI, then, according 
to IRFC32611, Section 8.1.1.8, "the Contact header field MUST contain 


a SIPS URI as well". This means that b@B, upon sending a new Request 
vithin the dialog (e.g., a BYE or re-INVITE), vill have to use a SIPS 
URI. If there is no Record-Route entry, or if the last Record-Route 


entry consists of a SIPS URI, this implies that b@B is expected to 
understand SIPS in the first place, and is required to also support 
TLS. If the last Record-Route entry however is a sip URI, then b 

vould be able to send requests vithout using TLS (but b vould still 


have to be able to handle SIPS schemes when parsing the message). In 
either case, the Request-URI in the request from b@B to B would be a 
SIPS URI. 

4. Overview of Operations 


Because of all the problems described in Section 3.3, this 
specification deprecates the last-hop exception vhen forvarding a 
request to the last hop (see Section 5.3). This vill ensure that TLS 
is used on all hops all the vay up to the remote target. 
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+------- + +------- + 
| Proxy | məm ILS---- | Proxy | 
L | kə 
L a + Ho + \ 
/ \ 
/ \ 
TLS TLS 
/ \ 
/ \ 
/ \ 
+------- + +------- + 
UAC a UAS b 
+------- + +------- + 
Domain A Domain B 
SIP trapezoid without last-hop exception 
The SIPS scheme implies transitive trust. Obviously, there is 
nothing that prevents proxies from cheating (see [RFC3261], Section 
26.4.4). While SIPS is useful to request that a resource be 


contacted securely, it is not useful as an indication that a resource 
was in fact contacted securely. Therefore, it is not appropriate to 
infer that because an incoming reguest had a Reguest-URI (or even a 
To header field) containing a SIPS URI, that it necessarily 
guarantees that the reguest was in fact transmitted securely on each 
hop. Some have been tempted to believe that the SIPS scheme was 
eguivalent to an HTTPS scheme in the sense that one could provide a 
visual indication to a user (e.g., a padlock icon) to the effect that 
the session is secured. This is obviously not the case, and 
therefore the meaning of a SIPS URI is not to be oversold. There is 
currently no mechanism to provide an indication of end-to-end 
security for SIP. Other mechanisms can provide a more concrete 
indication of some level of security. For example, SIP Identity 
[RFC4474] provides an authenticated identity mechanism and a domain- 
to-domain integrity protection mechanism. 


Some have asked why is SIPS useful in a global open environment such 
as the Internet, if (when used in a Reguest-URI) it is not an 
absolute guarantee that the reguest will in fact be delivered over 
TLS on each hop? Why is SIPS any different from just using TLS 
transport with SIP? The difference is that using a SIPS URI in a 
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Request-URI means that if you are instructing the netvork to use TLS 
over each hop and if it is not possible to reject the request, you 
vould rather have the request fail than have the request delivered 
without TLS. Just using TLS with a SIP Request-URI instead of a SIPS 
Request-URI implies a "best-effort" service: the request can but need 
not be delivered over TLS on each hop. 


Another common question is why not have a Proxy-Require and Require 
option tag forcing the use of TLS instead? The ansver is that it 
vould only be functionally equivalent to using SIPS in a Request-URI. 
SIPS URIs however can be used in many other header fields: in Contact 
for registration, Contact in dialog-creating requests, Route, Record- 
Route, Path, From, To, Refer-To, Referred-By, etc. SIPS URIs can 
also be used in human-usable format (e.g., business cards, user 
interface). SIPS URIs can even be used in other protocols or 
document formats that allov for including SIPS URIs (e.g., HTML). 


This document specifies that SIPS means that the SIP resource 
designated by the target SIPS URI is to be contacted securely, using 
TLS on each hop betveen the UAC and the remote UAS (as opposed to 
only to the proxy responsible for the target domain of the Request- 
URI). It is outside of the scope of this document to specify vhat 
happens vhen a SIPS URI identifies a UAS resource that "maps" outside 
the SIP network, for example, to other networks such as the Public 
Svitched Telephone Network (PSTN). 


4.1. Routing 


SIP and SIPS URIs that are identical except for the scheme itself 
(e.g., sip:alice@example.com and sips:alice@example.com) refer to the 
same resource. This requirement is implicit in [RFC3261], Section 
19.1, which states that "any resource described by a SIP URI can be 
"upgraded” to a SIPS URI by just changing the scheme, if it is 
desired to communicate vith that resource securely". This does not 
mean that the SIPS URI vill necessarily be reachable, in particular, 
if the proxy cannot establish a secure connection to a client or 
another proxy. This does not suggest either that proxies would 
arbitrarily "upgrade" SIP URIs to SIPS URIs vhen forvarding a request 
(see Section 5.3). Rather, it means that when a resource is 
addressable with SIP, it will also be addressable with SIPS. 


For example, consider the case of a UA that has registered with a 
SIPS Contact header field. If a UAC later addresses a request using 
a SIP Request-URI, the proxy will forward the request addressed to a 
SIP Request-URI to the UAS, as illustrated by message F13 in Sections 
6.3 and in 6.4. The proxy forvards the request to the UA using a SIP 
Request-URI and not the SIPS Request-URI used in registration. The 
proxy does this by replacing the SIPS scheme that was used in the 
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registered Contact header field binding vith a SIP scheme vhile 
leaving the rest of the URI as is, and then by using this nev URI as 
the Request-URI. If the proxy did not do this, and instead used a 
SIPS Request-URI, then the response (e.g., a 200 to an INVITE) vould 
have to include a SIPS Contact header field. That SIPS Contact 
header field vould then force the other UA to use a SIPS Contact 
header field in any mid-dialog request, including the ACK (vhich 
vould not be possible if that UA did not support SIPS). 


This specification mandates that vhen a proxy is forvarding a 
request, a resource described by a SIPS Request-URI cannot be 
"dovngraded" to a SIP URI by changing the scheme, or by sending the 
associated request over a nonsecure link. If a request needs to be 
rejected because otherwise it would be a "downgrade", the request 
vould be reğected vith a 480 (Temporarily Unavailable) response 
(potentially with a Warning header with varn-code 380 "SIPS Not 
Alloved"). Similarly, this specification mandates that vhen a proxy 
is forvarding a request, a resource described by a SIP Request-URI 
cannot be "upgraded" to a SIPS URI by changing the scheme (otherwise 
it would be an "upgrade" only for that hop onwards rather than on all 
hops, and would therefore mislead the UAS). If a request needs to be 
rejected because otherwise it would be a misleading "upgrade", the 
request would be rejected with a 480 (Temporarily Unavailable) 
response (potentially with a Warning header field with varn-code 381 
"SIPS Required"). See Section 5.3 for more details. 


For example, the sip:bob@example.com and sips:bob@example.com AORs 
refer to the same user "Bob" in the domain "example.com": the first 
URI is the SIP version, and the second one is the SIPS version. From 
the point of view of routing, requests to either sip:bob@example.com 
or sips:bob@example.com are treated the same way. When Bob 
registers, it therefore does not really matter if he is using a SIP 
or a SIPS AOR, since they both refer to the same user. At first 
glance, Section 19.1.4 of [RFC3261] seems to contradict this idea by 
stating that a SIP and a SIPS URI are never equivalent. 
Specifically, it says that they are never equivalent for the purpose 
Of comparing bindings in Contact header field URIs in REGISTER 
requests. The key point is that this statement applies to the 
Contact header field bindings in a registration: it is the 
association of the Contact header field vith the AOR that vill 
determine vhether or not the user is reachable vith a SIPS URI. 


Consider this example: if Bob (AOR bob@example.com) registers with a 
SIPS Contact header field (e.g., sips:bobübobphone.example.com), the 
registrar and the location service then knov that Bob is reachable at 
sips:bobübobphone.example.com and at sip:bob@bobphone.example.com. 
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If a request is sent to AOR sips:bob@example.com, Bob”s proxy will 
route it to Bob at Request-URI sips:bobübobphone.example.com. If a 
request is sent to AOR sip:bob@example.com, Bob's proxy will route it 
to Bob at Request-URI sip:bobübobphone.example.com. 


If Bob vants to ensure that every request delivered to him alvays be 
transported over TLS, Bob can use [RFC5626] when registering. 


However, if Bob had registered with a SIP Contact header field 
instead of a SIPS Contact header field (e.g., 
sip:bobübobphone.example.com), then a request to AOR 
sips:bob@example.com would not be routed to Bob, since there is no 
SIPS Contact header field for Bob, and "downgrades" from SIPS to SIP 
are not allowed. 


See Section 6 for illustrative call flows. 
5. Normative Requirements 


This section describes all the normative requirements defined by this 
specification. 


5.1. General User Agent Behavior 
5.1.1. UAC Behavior 


When presented with a SIPS URI, a UAC MUST NOT change it to a SIP 
URI. For example, if a directory entry includes a SIPS AOR, the UAC 
is not expected to send requests to that AOR using a SIP Request-URI. 
Similarly, if a user reads a business card with a SIPS URI, it is not 
possible to infer a SIP URI. If a 3XX response includes a SIPS 
Contact header field, the UAC does not replace it with a SIP Request- 
URI (e.g., by replacing the SIPS scheme with a SIP scheme) when 
sending a request as a result of the redirection. 


As mandated by [RFC3261], Section 8.1.1.8, in a request, "if the 
Request-URI or top Route header field value contains a SIPS URI, the 
Contact header field MUST contain a SIPS URI as vell". 


Upon receiving a 416 response or a 480 (Temporarily Unavailable) 
response with a Warning header with varn-code 380 "SIPS Not Allowed", 
a UAC MUST NOT re-attempt the request by automatically replacing the 
SIPS scheme with a SIP scheme as described in [RFC3261], Section 
8.1.3.5, as it would be a security vulnerability. If the UAC does 
re-attempt the call with a SIP URI, the UAC SHOULD get a confirmation 
from the user to authorize re-initiating the session with a SIP 
Request-URI instead of a SIPS Request-URI. 
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When the route set is not empty (e.g., when a service route [RFC3608] 
is returned by the registrar), it is the responsibility of the UAC to 


use a Route header field consisting of all SIPS URIs vhen using a 
SIPS Request-URI. Specifically, if the route set included any SIP 


URI, the UAC MUST change the SIP URIs to SIPS URIs simply by changing 


the scheme from "sip" to "sips" before sending the request. This 
allovs for configuring or discovering one service route vith all SIP 
URIs and alloving sending requests to both SIP and SIPS URIs. 


When the UAC is using a SIP Request-URI, if the route set is not 


empty and the topmost Route header field entry is a SIPS URI vith the 


lr parameter, the UAC MUST send the request over TLS (using a SIP 
Request-URI). If the route is not empty and the Route header field 
entry is a SIPS URI vithout the lr parameter, the UAC MUST send the 
request over TLS using a SIPS Request-URI corresponding to the 
topmost entry in the route set. 


To emphasize what is already defined in [RFC3261], UAs MUST NOT use 
the "transportetls" parameter. 


5.1.1.1. Registration 


The UAC registers Contacts header fields to either a SIPS or a SIP 
AOR. 


If a UA vishes to be reachable vith a SIPS URI, the UA MUST register 
with a SIPS Contact header field. Requests addressed to that UA”s 


AOR using either a SIP or SIPS Request-URI vill be routed to that UA. 
This includes UAs that support both SIP and SIPS. This specification 


does not provide any SIP-based mechanism for a UA to provision its 
proxy to only forvard requests using a SIPS Request-URI. A non-SIP 
mechanism such as a web interface could be used to provision such a 
preference. A SIP mechanism for provisioning such a preference is 
outside the scope of this specification. 


If a UA does not vish to be reached vith a SIPS URI, it MUST register 


vith a SIP Contact header field. 


Because registering vith a SIPS Contact header field implies a 


binding of both a SIPS Contact and a corresponding SIP Contact to the 


AOR, a UA MUST NOT include both the SIPS and the SIP versions of the 


same Contact header field in a REGISTER request, the UA MUST only use 


the SIPS version in this case. Similarly, a UA SHOULD NOT register 
both a SIP Contact header field and a SIPS Contact header field in 
separate registrations as the SIP Contact header field vould be 

superfluous. If it does, the second registration replaces the first 


one (e.g., a UA could register first vith a SIP Contact header field, 


meaning it does not support SIPS, and later register vith a SIPS 
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Contact header field, meaning it nov supports SIPS). Similarly, if a 
UA registers first vith a SIPS Contact header field and later 
registers vith a SIP Contact header field, that SIP Contact header 
field replaces the SIPS Contact header field. 


İRFC56261 can be used by a UA if it vants to ensure that no requests 
are delivered to it vithout using the TLS connection it used vhen 
registering. 


If all the Contact header fields in a REGISTER request are SIPS, the 
UAC MUST use SIPS AORs in the From and To header fields in the 
REGISTER request. If at least one of the Contact header fields is 
not SIPS (e.g., sip, mailto, tel, http, https), the UAC MUST use SIP 
AORs in the From and To header fields in the REGISTER request. 


To emphasize what is already defined in [RFC3261], UACs MUST NOT use 
the "transportetls" parameter. 


51:14:24 «STPS in a Dialog 


If the Request-URI in a request that initiates a dialog is a SIP URI, 
then the UAC needs to be careful about what to use in the Contact 
header field (in case Record-Route is not used for this hop). If the 
Contact header field vas a SIPS URI, it vould mean that the UAS vould 
only accept mid-dialog requests that are sent over secure transport 
on each hop. Since the Request-URI in this case is a SIP URI, it is 
quite possible that the UA sending a request to that URI might not be 
able to send requests to SIPS URIs. If the top Route header field 
does not contain a SIPS URI, the UAC MUST use a SIP URI in the 
Contact header field, even if the request is sent over a secure 
transport (e.g., the first hop could be re-using a TLS connection to 
the proxy as would be the case with [RFC5626]). 


When a target refresh occurs within a dialog (e.g., re-INVITE 
request, UPDATE request), the UAC MUST include a Contact header field 
with a SIPS URI if the original request used a SIPS Request-URI. 


5.1.1.3. Derived Dialogs and Transactions 
Sessions, dialogs, and transactions can be "derived" from existing 
ones. A good example of a derived dialog is one that was established 
as a result of using the REFER method [RFC3515]. 
As a general principle, derived dialogs and transactions cannot 


result in an effective downgrading of SIPS to SIP, without the 
explicit authorization of the entities involved. 
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For example, vhen a REFER request is used to perform a call transfer, 
it results in an existing dialog being terminated and another one 
being created based on the Refer-To URI. If that initial dialog vas 
established using SIPS, then the UAC MUST NOT establish a nev one 
using SIP, unless there is an explicit authorization given by the 
recipient of the REFER request. This could be a varning provided to 
the user. Having such a warning could be useful, for example, for a 
secure directory service application, to varn a user that a request 
may be routed to a UA that does not support SIPS. 


A REFER request can also be used for referring to resources that do 


not result in dialogs being created. In fact, a REFER request can be 
used to point to resources that are of a different type than the 
original one (i.e., not SIP or SIPS). Please see [RFC3515], Section 


5.2, for security considerations related to this. 


Other examples of derived dialogs and transactions include the use of 
Third-Party Call Control [RFC3725], the Replaces header field 
İRFC38911, and the Join header field [RFC3911]. Again, the general 
principle is that these mechanisms SHOULD NOT result in an effective 
dovngrading of SIPS to SIP, vithout the proper authorization. 


5.1.1.4. GRUU 


When a Globally Routable User Agent URI (GRUU) [RFC5627] is assigned 
to an instance ID/AOR pair, both SIP and SIPS GRUUs vill be assigned. 
When a GRUU is obtained through registration, if the Contact header 
field in the REGISTER request contains a SIP URI, the SIP version of 
the GRUU is returned. If the Contact header field in the REGISTER 
request contains a SIPS URI, the SIPS version of the GRUU is 
returned. 


If the wrong scheme is received in the GRUU (which would be an error 
in the registrar), the UAC SHOULD treat it as if the proper scheme 
vas used (i.e., it SHOULD replace the scheme vith the proper scheme 
before using the GRUU). 
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5.1.2. UAS Behavior 


When presented with a SIPS URI, a UAS MUST NOT change it to a SIP 
URI. 


As mandated by [RFC3261], Section 12.1.1: 


If the request that initiated the dialog contained a SIPS URI in 
the Request-URI or in the top Record-Route header field value, if 
there was any, or the Contact header field if there was no Record- 
Route header field, the Contact header field in the response MUST 
be a SIPS URI. 


If a UAS does not wish to be reached with a SIPS URI but only with a 
SIP URI, the UAS MUST respond with a 480 (Temporarily Unavailable) 
response. The UAS SHOULD include a Warning header with warn-code 380 
"SIPS Not Allowed". [REC3261], Section 8.2.2.1, states that UASs 
that do not support the SIPS URI scheme at all "SHOULD reject the 
request with a 416 (Unsupported URI scheme) response". 


If a UAS does not wish to be contacted with a SIP URI but instead by 
a SIPS URI, it MUST reject a request to a SIP Request-URI with a 480 
(Temporarily Unavailable) response. The UAS SHOULD include a Warning 
header with warn-code 381 "SIPS Required". 


It is a matter of local policy for a UAS to accept incoming requests 
addressed to a URI scheme that does not correspond to what it used 
for registration. For example, a UA with a policy of "always SIPS" 
would address the registrar using a SIPS Request-URI over TLS, would 
register with a SIPS Contact header field, and the UAS would reject 
requests using the SIP scheme with a 480 (Temporarily Unavailable) 
response with a Warning header with warn-code 381 "SIPS Required". A 
UA with a policy of "best-effort SIPS" would address the registrar 
using a SIPS Request-URI over TLS, would register with a SIPS Contact 
header field, and the UAS would accept requests addressed to either 
SIP or SIPS Request-URIs. A UA with a policy of "No SIPS" would 
address the registrar using a SIP Request-URI, could use TLS or not, 
would register with a SIP AOR and a SIP Contact header field, and the 
UAS would accept requests addressed to a SIP Request-URI. 


If a UAS needs to reject a request because the URIs are used 
inconsistently (e.g., the Request-URI is a SIPS URI, but the Contact 
header field is a SIP URI), the UAS MUST reject the request with a 
400 (Bad Request) response. 


When a target refresh occurs within a dialog (e.g., re-INVITE 


request, UPDATE request), the UAS MUST include a Contact header field 
with a SIPS URI if the original request used a SIPS Request-URI. 


Audet Standards Track [Page 17] 


RFC 5630 SIPS October 2009 


To emphasize what is already defined in [RFC3261], UASs MUST NOT use 
the "transportetls" parameter. 


5.2. Registrar Behavior 


The UAC registers Contacts header fields to either a SIPS or a SIP 
AOR. From a routing perspective, it does not matter vhich one is 
used for registration as they identify the same resource. The 
registrar MUST consider AORs that are identical except for one having 
the SIP scheme and the other having the SIPS scheme to be equivalent. 


A registrar MUST accept a binding to a SIPS Contact header field only 
if all the appropriate URIs are of the SIPS scheme, othervise, there 
could be an inadvertent binding of a secure resource (SIPS) to an 
unsecured one (SIP). This includes the Request-URI and the Contacts 
and all the Path header fields, but does not include the From and To 
header fields. If the URIs are not of the proper SIPS scheme, the 
registrar MUST reject the REGISTER with a 400 (Bad Request). 


A registrar can return a service route [RFC3608] and impose some 
constraints on whether or not TLS will be mandatory on specific hops. 
For example, if the topmost entry in the Path header field returned 
by the registrar is a SIPS URI, the registrar is telling the UAC that 
TLS is to be used for the first hop, even if the Request-URI is SIP. 


If a UA registered with a SIPS Contact header field, the registrar 
returning a service route [RFC3608] MUST return a service route 
consisting of SIP URIs if the intent of the registrar is to allow 
both SIP and SIPS to be used in requests sent by that client. If a 
UA registers with a SIPS Contact header field, the registrar 
returning a service route MUST return a service route consisting of 
SIPS URIs if the intent of the registrar is to allow only SIPS URIs 
to be used in requests sent by that UA. 


5.2.1.  GRUU 


When a GRUU [RFC5627] is assigned to an instance ID/AOR pair through 
registration, the registrar MUST assign both a SIP GRUU and a SIPS 
GRUU. If the Contact header field in the REGISTER request contains a 
SIP URI, the registrar MUST return the SIP version of the GRUU. If 
the Contact header field in the REGISTER request contains a SIPS URI, 
the registrar MUST return the SIPS version of the GRUU. 


5.3. Proxy Behavior 
Proxies MUST NOT use the last-hop exception of [RFC3261] when 


forwarding or retargeting a request to the last hop. Specifically, 
when a proxy receives a request with a SIPS Request-URI, the proxy 
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MUST only forvard or retarget the request to a SIPS Request-URI. If 
the target UAS had registered previously using a SIP Contact header 
field instead of a SIPS Contact header field, the proxy MUST NOT 
forvard the request to the URI indicated in the Contact header field. 
If the proxy needs to reject the request for that reason, the proxy 
MUST reject it with a 480 (Temporarily Unavailable) response. In 
this case, the proxy SHOULD include a Narning header vith varn-code 
380 "SIPS Not Alloved". 


Proxies SHOULD transport requests using a SIP URI over TLS vhen it is 
possible to set up a TLS connection, or reuse an existing one. 
İRFC56261, for example, allovs for re-using an existing TLS 
connection. Some proxies could have policies that prohibit sending 
any request over anything but TLS. 


When a proxy receives a request with a SIP Request-URI, the proxy 
MUST NOT forvard the request to a SIPS Request-URI. If the target 
UAS had registered previously using a SIPS Contact header field, and 
the proxy decides to forvard the request, the proxy MUST replace that 
SIPS scheme vith a SIP scheme vhile leaving the rest of the URI as 
is, and use the resulting URI as the Request-URI of the forvarded 
request. The proxy MUST use TLS to forvard the request to the UAS. 
Some proxies could have a policy of not forvarding at all requests 
using a non-SIPS Request-URI if the UAS had registered using a SIPS 
Contact header field. If the proxy elects to reject the request 
because it has such a policy or because it is not capable of 
establishing a TLS connection, the proxy MAY reject it with a 480 
(Temporarily Unavailable) response with a Warning header with warn- 
code 381 "SIPS Required". 


If a proxy needs to reject a request because the URIs are used 
inconsistently (e.g., the Request-URI is a SIPS URI, but the Contact 
header field is a SIP URI), the proxy SHOULD use response code 400 
(Bad Request). 


It is RECOMMENDED that the proxy use the outbound proxy procedures 
defined in [RFC5626] for supporting UACs that cannot provide a 
certificate for establishing a TLS connection (i.e., vhen server-side 
authentication is used). 


When a proxy sends a request using a SIPS Request-URI and receives a 
3XX response with a SIP Contact header field, or a 416 response, or a 
480 (Temporarily Unavailable) response with a Warning header with 
warn-code 380 "SIPS Not Allowed" response, the proxy MUST NOT recurse 
on the response. In this case, the proxy SHOULD forward the best 
response instead of recursing, in order to allow for the UAC to take 
the appropriate action. 
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When a proxy sends a request using a SIP Request-URI and receives a 
3XX response vith a SIPS Contact header field, or a 480 (Temporarily 
Unavailable) response with a Warning header with varn-code 381 "SIPS 
Required", the proxy MUST NOT recurse on the response. In this case, 
the proxy SHOULD forvard the best response instead of recursing, in 
order to allov for the UAC to take the appropriate action. 


To emphasize what is already defined in [RFC3261], proxies MUST NOT 
use the "transportetls" parameter. 


5.4. Redirect Server Behavior 


Using a redirect server vith TLS instead of using a proxy has some 
limitations that have to be taken into account. Since there is no 
pre-established connection betveen the proxy and the UAS (such as 
with [RFC5626]), it is only appropriate for scenarios where inbound 
connections are alloved. For example, it could be used in a server- 
to-server environment (redirect server or proxy server) vhere TLS 
mutual authentication is used, and vhere there are no NAT traversal 
issues. A redirect server vould not be able to redirect to an entity 
that does not have a certificate. A redirect server might not be 
usable if there is a NAT betveen the server and the UAS. 


When a redirect server receives a request with a SIP Request-URI, the 
redirect server MAY redirect with a 3XX response to either a SIP or a 
SIPS Contact header field. If the target UAS had registered 
previously using a SIPS Contact header field, the redirect server 
SHOULD return a SIPS Contact header field if it is in an environment 
where TLS is usable (as described in the previous paragraph). If the 
target UAS had registered previously using a SIP Contact header 
field, the redirect server MUST return a SIP Contact header field in 
a 3XX response if it redirects the request. 


When a redirect server receives a request with a SIPS Request-URI, 
the redirect server MAY redirect with a 3XX response to a SIP or a 
SIPS Contact header field. If the target UAS had registered 
previously using a SIPS Contact header field, the redirect server 
SHOULD return a SIPS Contact header field if it is in an environment 
where TLS is usable. If the target UAS had registered previously 
using a SIP Contact header field, the redirect server MUST return a 
SIP Contact header field in a 3XX response if it chooses to redirect; 
otherwise, the UAS MAY reject the request with a 480 (Temporarily 
Unavailable) response with a Warning header with warn-code 380 "SIPS 
Not Allowed". If a redirect server redirects to a UAS that it has no 
knowledge of (e.g., an AOR in a different domain), the Contact header 
field could be of any scheme. 
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If a redirect server needs to reject a request because the URIs are 
used inconsistently (e.g., the Request-URI is a SIPS URI, but the 
Contact header field is a SIP URI), the redirect server SHOULD use 
response code 400 (Bad Request). 


To emphasize what is already defined in [RFC3261], redirect servers 
MUST NOT use the "transportetls" parameter. 


6. Call Flovs 


The following diagram illustrates the topology used for the examples 
in this section: 


example.com : example.net 
Registrar/ | Proxy A | 
| Auth. Proxy | : İ (proxya) İ 
| (pb) | . İr | 
s üz | 
| | 
|----=------ | | 
| Edge | | 
Proxy B | 
İ (eb) | | 
| | | 
/ 
| 
/ | | 
| | 
| | AA ; 2. 
| | 0430 : 0/7 NGO 
/“  / /— N 1 / N 
bobübobpc bob@bobphone B alice 
Topologv 


In the following examples, Bob has two clients; one is a SIP PC 
client running on his computer, and the other one is a SIP phone. 
The PC client does not support SIPS, and consequently only registers 
vith a SIP Contact header field. The SIP phone hovever does support 
SIPS and TLS, and consequently registers vith a SIPS Contact header 
field. Both of Bob”s devices are going through Edge Proxy B, and 
consequently, they include a Route header field indicating 
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eb.example.com. Edge Proxy B removes the Route header field 
corresponding to itself, and adds itself in a Path header field. The 
registration process call flow is illustrated in Section 6.1. 


After registration, there are two Contact bindings associated with 
Bob” s AOR of bob@example.com: sips:bobübobphone.example.com and 
sip:bobübobpc.example.com. 


Alice then calls Bob through her ovn Proxy A. Proxy A locates Bob”s 
domain example.com. In this example, that domain is owned by Bob”s 
Registrar/Authoritative Proxy B. Proxy A removes the Route header 
field corresponding to itself, and inserts itself in the Record-Route 
and forvards the request to Registrar/Authoritative Proxy B. 


The folloving subsections illustrate registration and three examples. 
In the first example (Section 6.2), Alice calls Bob”s SIPS AOR. In 
the second example (Section 6.3), Alice calls Bob”s SIP AOR using TCP 
transport. In the third example (Section 6.4), Alice calls Bob”s SIP 
AOR using TLS transport. 


6.1. Bob Registers His Contacts 
This flov illustrates the registration process by vhich Bob”s device 


registers. His PC client (Bobübobpc) registers vith a SIP scheme, 
and his SIP phone (Bobüphone) registers vith a SIPS scheme. 
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Message details 


Bob Registers His Contacts 


F1 REGISTER Bob”s PC Client -> Edge Proxy B 


REGISTER sip:pb.example.com SIP/2.0 
Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKnashds 


Max-Forwards: 70 


To: Bob <sip:bob@example.com> 
From: Bob xsip:bob@example. com”, tag=456248 
Call-ID: 843817637684230@998sdasdh09 


CSeq: 1826 REGISTER 


Supported: path, outbound 

Route: <sip:eb.example.com; 1r> 

Contact: <sip:bob@bobpc.example.com> 
¿+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>" 


; reg-id=1 
Content-Length: 0 
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F2 REGISTER Edge Proxy B -> Registrar/Authoritative Proxy B 


REGISTER sip:pb.example.com SIP/2.0 

Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bK87asdks7 

Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKnashds 

Max-Forvards: 69 

To: Bob <sip:bob@example.com> 

From: Bob xsip:bob@example. com”, tag-456248 

Call-ID: 843817637684230@998sdasdh09 

CSeq: 1826 REGISTER 

Supported: path, outbound 

Path: <sip:laksdyjanseg237+fsdftuy623hytIJ8@eb.example.com; lr; ob> 

Contact: <sip:bob@bobpc.example.com> 
;tsip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>" 
; reg-id=1 

Content-Length: 0 


F3 200 (REGISTER) Registrar/Authoritative Proxy B -> Edge Proxy B 


SIP/2.0 200 OK 

Via: SIP/2.0/TCP eb.example.com:5060,branchez9hG4bK87asdks7 

Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKnashds 

To: Bob <sip:bobfexample.com>;tag=2493K59K9 

From: Bob <sip:bobfexample.com>;tag=456248 

Call-ID: 843817637684230@998sdasdh09 

CSeq: 1826 REGISTER 

Require: outbound 

Supported: path, outbound 

Path: <sip:laksdyjanseg237+fsdftuy623hytIJ8@eb.example.com; lr; ob> 

Contact: <sip:bob@bobphone.example.com> 
;tsip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>" 
;reg-id=1 
; expires=3600 

Date: Mon, 12 Jun 2006 16:43:12 GMT 

Content-Length: 0 
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F4 200 (REGISTER) Edge Proxy B -> Bob”s PC Client 


SIP/2.0 200 OK 

Via: SIP/2.0/TCP bobpc.example.com:5060;branch=z9hG4bKnashds 

To: Bob <sip:bob@example.com>;tag=2493K59K9 

From: Bob <sip:bobfexample.com>;tag=456248 

Call-ID: 843817637684230@998sdasdh09 

CSeq: 1826 REGISTER 

Require: outbound 

Supported: path, outbound 

Path: <sip:laksdyjanseg237+fsdftuy623hytIJ8@eb.example.com; lr; ob> 

Contact: <sip:bob@bobphone.example.com> 
¿+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>" 
; reg-id=1 
; expires=3600 

Date: Thu, 09 Aug 2007 16:43:12 GMT 

Content-Length: 0 


F5 REGISTER Bob”s Phone -> Edge Proxy B 


REGISTER sips:pb.example.com SIP/2.0 

Via: SIP/2.0/TLS bobphone.example.com:5061,branchez9hG4bK9555 

Max-Forvards: 70 

To: Bob <sips:bob@example.com> 

From: Bob <sips:bobfexample.com>;tag=90210 

Call-ID: faif9a@qwefnwdclk 

CSeq: 12 REGISTER 

Supported: path, outbound 

Route: <sips:eb.example.com;lr> 

Contact: <sips:bob@bobphone.example.com> 
¿+sip.instance="<urn:uuid: 6F85D4E3-E8AA-46AA-B768-BF39D5912143>" 
;reg-id-1 

Content-Length: 0 
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F6 REGISTER Edge Proxy B -5 Registrar/Authoritative Proxy B 


REGISTER sips:pb.example.com SIP/2.0 

Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bK876354 

Via: SIP/2.0/TLS bobphone.example.com:5061,branchez9hG4bK9555 

Max-Forvards: 69 

To: Bob <sips:bob@example.com> 

From: Bob <sips:bobfexample.com>;tag=90210 

Call-ID: faif9a@qwefnwdclk 

CSeq: 12 REGISTER 

Supported: path, outbound 

Path: <sips:psodkfs3+34+kk1sL+uJH-Xm816k09Kkfteb.example.com;1r;ob> 

Contact: <sips:bob@bobphone.example.com> 
¿+sip.instance="<urn:uuid: 6F85D4E3-E8AA-46AA-B768-BF39D5912143>" 
;reg-id=1 

Content-Length: 0 


F7 200 (REGISTER) Registrar/Authoritative Proxy B -> Edge Proxy B 


SIP/2.0 200 OK 

Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bK876354 

Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555 

To: Bob <sips:bob@example.com>;tag=5150 

From: Bob <sips:bobfexample.com>;tag=90210 

Call-ID: faif9a@qwefnwdclk 

CSeq: 12 REGISTER 

Require: outbound 

Supported: path, outbound 

Path: <sips:psodkfs3+34+kk1sL+uJH-Xm816k09Kkfteb.example.com;1r;ob> 

Contact: <sips:bob@bobphone.example.com> 
¿+sip.instance="<urn:uuid: 6F85D4E3-E8AA-46AA-B768-BF39D5912143>" 
;reg-id=1 
; expires=3600 

Date: Thu, 09 Aug 2007 16:43:50 GMT 

Content-Length: 0 
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F8 200 (REGISTER) Edge Proxy B -> Bob”s Phone 


SIP/2.0 200 OK 

Via: SIP/2.0/TLS bobphone.example.com:5061,branchez9hG4bK9555 

To: Bob <sips:bob@example.com>;tag=5150 

From: Bob <sips:bob@example.com>;tag=90210 

Call-ID: faif9a@qwefnwdclk 

CSeq: 12 REGISTER 

Require: outbound 

Supported: path, outbound 

Path: <sips:psodkfs3+34+kk1sL+uJH-Xm816k09Kkfteb.example.com;1r;ob> 

Contact: <sips:bob@bobphone.example.com> 
;+sip.instance="<urn:uuid: 6F85D4E3-E8AA-46AA-B768-BF39D5912143>" 
; reg-id=1 
; expires=3600 

Date: Thu, 09 Aug 2007 16:43:50 GMT 

Content-Length: 0 


6.2. Alice Calls Bob's SIPS AOR 


Bob's registration has already occurred as per Section 6.1. 


In this first example, Alice calls Bob's SIPS AOR 
(sips:bob@example.com). Registrar/Authoritative Proxy B consults the 
binding in the registration database, and finds the two Contact 
header field bindings. Alice had addressed Bob vith a SIPS Request- 
URI (sips:bobüexample.com), so Registrar/Authoritative Proxy B 
determines that the call needs to be routed only to bobphone (vhich 
registered using a SIPS Contact header field), and therefore the 
request is only sent to sips:bobübobphone.example.com, through Edge 
Proxy B. Both Registrar/Authoritative Proxy B and Edge Proxy B 
insert themselves in the Record-Route. Bob ansvers at 
sips:bobübobphone.example.com. 
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(eb) (pb) 
Edge Registrar/ 
eure -- B B A B Proxy A Alice 

| | | | INVITE F9 | 

| Bob@bobphone | | INVITE F11 |<----------- 

| | INVITE F13 |<----------- | 100 F10 | 

| | INVITE F15 |<----------- | 100 F12 1----------- >| 

x——————————— 100 F14 1-------———— > 

ə: ; 

| |----------- >| 180 F17 | | | 

| | 200 F20 |----------- >| 180 F18 | 

| |----------- >| 200 F21 |----------- >| 180 F19 | 

| | |----------- >| 200 F22 |----------- >| 

| | İİ [eo >| 200 F23 
əzizim əri əm $ 

| | | ACK F24 

| | | | ACK F25 |<----------- | 

| | | ACK F26 |<----------- | 

| | ACK F27 |<----------- | | | 

| [> | | | | 

| | | | 


Alice Calls Bob's SIPS AOR 


Message details 
F9 INVITE Alice -5 Proxy A 


INVITE sips:bob@example.com SIP/2.0 
Via: 
Max-Forwards: 70 

To: Bob <sips:bob@example.com> 


SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout 


From: Alice <sips:alice@example.net>;tag=8675309 


Call-ID: l1zks?f8723k6sodk6587 
CSeq: 1 INVITE 
Route: <sips:proxya.example.net;1r> 


Contact: 


<sips:alicefalice-l.example.net> 


Content-Type: 


application/sdp 


Content-Length: 
(SDP not shown) 


Audet 


(as per SDP) 
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F10 100 (INVITE) Proxy A -> Alice 


SIP/2.0 100 Trying 

Via: SIP/2.0/TLS alice-l.example.net:5061,branchez9hGibKprout 
To: Bob <sips:bob@example.com> 

From: Alice <sips:alice@example.net>;tag=8675309 

Call-ID: l1zks?f8723k6sodk6587 

CSeq: 1 INVITE 

Content-Length: 0 


F11 INVITE Proxy A -> Registrar/Authoritative Proxy B 


INVITE sips:bob@example.com SIP/2.0 

Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet 
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout 
Max-Forwards: 69 

To: Bob <sips:bob@example.com> 

From: Alice <sips:alice@example.net>;tag=8675309 

Call-ID: l1zks?f8723k6sodk6587 

CSeq: 1 INVITE 

Record-Route: <sips:proxya.example.net;lr> 

Contact: <sips:alicefalice-l.example.net> 

Content-Type: application/sdp 

Content-Length: (as per SDP) 

(SDP not shovn) 


F12 100 (INVITE) Registrar/Authoritative Proxy B -> Proxy A 


SIP/2.0 100 Trying 

Via: SIP/2.0/TLS proxya.example.net:5061,branchez9hGibKpouet 
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout 
To: Bob <sips:bob@example.com> 

From: Alice <sips:alice@example.net>;tag=8675309 

Call-ID: 1zks3jf8723kGsodk6587 

CSeq: 1 INVITE 

Content-Length: 0 
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F13 INVITE Registrar/Authoritative Proxy B -5 Edge Proxy B 


INVITE sips:bobübobphone.example.com SIP/2.0 

Via: SIP/2.0/TLS pb.example.com:5061,branchez9hGibKbalouba 

Via: SIP/2.0/TLS proxya.example.net:5061,branchez9hGibKpouet 

Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout 

Max-Forvards: 68 

To: Bob <sips:bob@example.com> 

From: Alice <sips:alice@example.net>;tag=8675309 

Call-ID: 1zks3jf8723kGsodk6587 

CSeq: 1 INVITE 

Route: 
<sips:psodkfsj+34+kklsL+uJH-Xm816k09Kkfedge.example.com; lr; ob> 

Record-Route: <sips:pb.example.com; lr>, <sips:proxya.example.net;1r> 

Contact: <sips:alicefalice-l.example.net> 

Content-Type: application/sdp 

Content-Length: (as per SDP) 

(SDP not shown) 


F14 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B 


SIP/2.0 100 Trying 

Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba 
Via: SIP/2.0/TLS proxya.example.net:5061,branchez9hGibKpouet 
Via: SIP/2.0/TLS alice-l.example.net:5061,branchez9hGibKprout 
To: Bob <sips:bob@example.com> 

From: Alice <sips:alice@example.net>;tag=8675309 

Call-ID: 1zksjf8723kGsodk6587 

CSeg: 1 INVITE 

Content-Length: 0 
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F15 INVITE Edge Proxy B -> Bob” s phone 


INVITE sips:bobübobphone.example.com SIP/2.0 

Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKbiba 

Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba 

Via: SIP/2.0/TLS proxya.example.net:5061,branchez9hGibKpouet 

Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout 

Max-Forvards: 67 

To: Bob <sips:bob@example.com> 

From: Alice <sips:alice@example.net>;tag=8675309 

Call-ID: 1zks3jf8723kGsodk6587 

CSeq: 1 INVITE 

Record-Route: 
<sips:psodkfsj+34+kk1sL+uJH-Xm816k09Kk@eb.example.com;1lr;ob>, 
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr> 

Contact: <sips:alicefalice-l.example.net> 

Content-Type: application/sdp 

Content-Length: {as per SDP} 

{SDP not shown} 


F16 180 (INVITE) Bob’s Phone -> Edge Proxy B 


SIP/2.0 180 Ringing 

Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKbiba 

Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba 

Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet 

Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout 
To: Bob <sips:bob@example.com>;tag=5551212 

From: Alice <sips:alice@example.net>;tag=8675309 

Call-ID: l1zks?f8723k6sodk6587 

CSeq: 1 INVITE 

Record-Route: 
<sips:psodkfsj+34+kk1lsL+uJH-Xm816k09Kk@eb.example.com;1lr;ob>, 
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr> 

Contact: <sips:bob@bobphone.example.com> 

Content-Length: 0 
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F17 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B 


SIP/2.0 180 Ringing 

Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba 

Via: SIP/2.0/TLS proxya.example.net:5061,branchez9hGibKpouet 

Via: SIP/2.0/TLS alice-l.example.net:5061,branchez9hGibKprout 

To: Bob <sips:bob@example.com>;tag=5551212 

From: Alice <sips:alice@example.net>;tag=8675309 

Call-ID: l1zks?f8723k6sodk6587 

CSeq: 1 INVITE 

Record-Route: 
<sips:psodkfsj+34+kk1lsL+uJH-Xm816k09Kk@eb.example.com;1r;ob>, 
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr> 

Contact: <sips:bob@bobphone.example.com> 

Content-Length: 0 


F18 180 Registrar/Authoritative Proxy B -> Proxy A 


SIP/2.0 180 Ringing 

Via: SIP/2.0/TLS proxya.example.net:5061,branchez9hGibKpouet 

Via: SIP/2.0/TLS alice-l.example.net:5061,branchez9hGibKprout 

To: Bob <sips:bob@example.com>;tag=5551212 

From: Alice <sips:alice@example.net>;tag=8675309 

Call-ID: 1zks?f8723k6sodk6587 

CSeq: 1 INVITE 

Record-Route: 
<sips:psodkfsj+34+kk1lsL+uJH-Xm816k09Kk@eb.example.com;1r;ob>, 
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr> 

Contact: <sips:bob@bobphone.example.com> 

Content-Length: 0 


F19 180 (INVITE) Proxy A -> Alice 


sIP/2.0 180 Ringing 

Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout 
To: Bob <sips:bob@example.com>;tag=5551212 

From: Alice <sips:alice@example.net>;tag=8675309 

Call-ID: 1zks3jf8723kGsodk6587 

CSeq: 1 INVITE 

Record-Route: 
<sips:psodkfsj+34+kk1sL+uJH-Xm816k09Kk@eb.example.com;1r;ob>, 
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr> 

Contact: <sips:bob@bobphone.example.com> 

Content-Length: 0 
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F20 200 (INVITE) Bob”s Phone -> Edge Proxy B 


SIP/2.0 200 OK 

Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKbiba 

Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba 

Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet 

Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout 
To: Bob <sips:bob@example.com>;tag=5551212 

From: Alice <sips:alice@example.net>;tag=8675309 

Call-ID: 1zks3jf8723kGsodk6587 

CSeq: 1 INVITE 

Record-Route: 
<sips:psodkfsj+34+kk1lsL+uJH-Xm816k09Kk@eb.example.com;1r;ob>, 
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr> 

Contact: <sips:bob@bobphone.example.com> 

Content-Length: 0 


F21 200 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B 


SIP/2.0 200 OK 

Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bKbalouba 

Via: SIP/2.0/TLS proxya.example.net:5061,branchez9hGibKpouet 

Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout 
To: Bob <sips:bob@example.com>;tag=5551212 

From: Alice <sips:alice@example.net>;tag=8675309 

Call-ID: l1zks?f8723k6sodk6587 

CSeq: 1 INVITE 
Record-Route: 
<sips:psodkfsj+34+kk1lsL+uJH-Xm816k09Kk@eb.example.com;1r;ob>, 
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr> 

Contact: <sips:bob@bobphone.example.com> 

Content-Length: 0 
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F22 200 Registrar/Authoritative Proxy B -> Proxy A 


SIP/2.0 200 OK 

Via: SIP/2.0/TLS proxya.example.net:5061,branchez9hGibKpouet 

Via: SIP/2.0/TLS alice-l.example.net:5061,branchez9hGibKprout 
To: Bob <sips:bob@example.com>;tag=5551212 

From: Alice <sips:alice@example.net>;tag=8675309 

Call-ID: 1zks3jf8723kGsodk6587 

CSeq: 1 INVITE 

Record-Route: 
<sips:psodkfsj+34+kk1sL+uJH-Xm816k09Kk@eb.example.com;1r;ob>, 
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr> 

Contact: <sips:bob@bobphone.example.com> 

Content-Length: 0 


F23 200 (INVITE) Proxy A -> Alice 


SIP/2.0 200 OK 

Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout 

To: Bob <sips:bob@example.com>;tag=5551212 

From: Alice <sips:alice@example.net>;tag=8675309 

Call-ID: l1zks?f8723k6sodk6587 

CSeq: 1 INVITE 

Record-Route: 
<sips:psodkfsj+34+kk1lsL+uJH-Xm816k09Kk@eb.example.com;1lr;ob>, 
<sips:pb.example.com;lr>, <sips:proxya.example.net;lr> 

Contact: <sips:bob@bobphone.example.com> 

Content-Length: 0 


F24 ACK Alice -> Proxy A 


ACK sips:bob@bobphone.example.com SIP/2.0 

Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf 

Max-Forvards: 70 

To: Bob <sips:bob@example.com>;tag=5551212 

From: Alice <sips:alice@example.net>;tag=8675309 

Call-ID: 1lzksjf£8723k@sodk6587 

CSeq: 1 ACK 

Route: <sips:proxya.example.net;lr>, <sips:pb.example.com;lr>, 
<sips:psodkfs3+34+kk1sL+uJH-Xm816k09Kkfpb.example.com;1r;ob> 

Content-Length: 0 
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F25 ACK Proxy A -> Registrar/Authoritative Proxy B 


ACK sips:bobübobphone.example.com SIP/2.0 

Via: SIP/2.0/TLS proxya.example.net:5061,branchez9hG4bKplo7hy 

Via: SIP/2.0/TLS alice-1l.example.net:5061;branch=z9hG4bKksdjf 

Max-Forvards: 69 

To: Bob <sips:bob@example.com>;tag=5551212 

From: Alice <sips:alice@example.net>;tag=8675309 

Call-ID: l1zks?f8723k6sodk6587 

CSeq: 1 ACK 

Route: <sips:pb.example.com;1r>, 
<sips:psodkfs3+34+kk1sL+uJH-Xm816k09Kkfpb.example.com;1r;ob> 

Content-Length: 0 


F26 ACK Registrar/Authoritative Proxy B -5 Edge Proxy B 


ACK sips:bobübobphone.example.com SIP/2.0 

Via: SIP/2.0/TLS pb.example.com:5061;branch=z9hG4bK8msdu2 

Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy 

Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf 

Max-Forvards: 69 

To: Bob <sips:bob@example.com>;tag=5551212 

From: Alice <sips:alice@example.net>;tag=8675309 

Call-ID: 1zks3jf8723kGsodk6587 

CSeq: 1 ACK 

Route: <sips:pb.example.com;1r>, 
<sips:psodkfs3+34+kk1sL+uJH-Xm816k09Kkfpb.example.com;1r;ob> 

Content-Length: 0 


F27 ACK Proxy B -> Bob”s Phone 


ACK sips:bobübobphone.example.com SIP/2.0 

Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKkmfdgk 
Via: SIP/2.0/TLS pb.example.com:5061,branchez9hG4bK8msdu2 
Via: SIP/2.0/TLS proxya.example.net:5061,branchez9hG4bKplo7hy 
Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf 
Max-Forvards: 68 

To: Bob <sips:bob@example.com>;tag=5551212 

From: Alice <sips:alice@example.net>;tag=8675309 

Call-ID: 1lzksjf£8723k@sodk6587 

CSeq: 1 ACK 

Content-Length: 0 
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6.3. Alice Calls Bob”s SIP AOR Using TCP 
Bob” s registration has already occurred as per Section 6.1. 


In the second example, Alice calls Bob”s SIP AOR instead 
(sip:bob@example.com), and she uses TCP as a transport. Registrar/ 
Authoritative Proxy B consults the binding in the registration 
database, and finds the tvo Contact header field bindings. Alice had 
addressed Bob with a SIP Request-URI (sip:bob@example.com), so 
Registrar/Authoritative Proxy B determines that the call needs to be 
routed both to bobpc (which registered with a SIP Contact header 
field) and bobphone (which registered with a SIPS Contact header 
field), and therefore the request is forked to 
sip:bob@bobpc.example.com and sip:bobübobphone.example.com, through 
Edge Proxy B. Note that Registrar/Authoritative Proxy B preserved 
the SIP scheme of the Request-URI instead of replacing it vith the 
SIPS scheme of the Contact header field that vas used for 
registration. Both Registrar/Authoritative Proxy B and Edge Proxy B 
insert themselves in the Record-Route. Bob's phone”s policy is to 
accept calls to SIP and SIPS (i.e., "best effort"), so both his PC 
client and his SIP phone ring simultaneously. Bob ansvers on his SIP 
phone, and the forked call leg to the PC client is canceled. 
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(eb) (pb) 
Edge Registrar/ 

1 -- B -.— B R. A Alice 
| | | | INVITE F9 | 
| | | INVITE F11 |<----------- | 
| | INVITE F13' |<----------- | 100 F10 | 
| INVITE F15” | <----------- | 100 F12 1----------- >| 
x—————————————————— 100 F14: |----------- > 

180 F16” | -—————————— > | 
| ------------------ >| 180 F17' | | | 
Ə XyU UX I >| 180 F18' | 

Bob@bobphone | S X yV(İ-——------ > 180 F19” | 
| INVITE F13İ S 0 --———--—-- >| 
| INVITE F15 |<----------- | | 
<----------- 100 F14 
180 F16 | -—-———————— > | 
İ 01-—--------- >| 180 F17 | | | 
| | 200 F20 |----------- >| 180 F18 | 
| İ----------- >| 200 F21 1İ----------- >| 180 F19 | 
| | | ----------- >| 200 F22  |----------- > | 
-—————————— > 200 F23 
| —— “ > 
| | ACK F24 
| | | ACK F25 1-——--------- | 
| | ACK F26 1İ1------------ | | 
| ACK F27 |<----------- | 
|<----------- 

CANCEL F26' | 
| CANCEL F27' | <----------- | | | 
Is-4 | | | | 
| 200 F287 | | | | 
| ------------------ >| 200 F29” | | | 

487 F30’ 90-———--—---- > 
------------------ > 487 F31' | | 
| |----------- >| | 


Alice Calls Bob's SIP AOR 
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Message details 
F9 INVITE Alice -5 Proxy A 


INVITE sip:bob@example.com SIP/2.0 

Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 
Max-Forwards: 70 

To: Bob <sip:bob@example.com> 

From: Alice <sip:alice@example.net>;tag=8675309 
Call-ID: l1zks?f8723k6sodk6587 

CSeq: 1 INVITE 

Route: <sip:proxya.example.net;lr> 

Contact: <sip:alice@alice-1.example.net> 
Content-Type: application/sdp 

Content-Length: (as per SDP) 

(SDP not shown) 


r10 100 (INVITE) Proxy A -> Alice 


sIP/2.0 100 Trying 

Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 
To: Bob <sip:bob@example.com> 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: 1zks3jf8723kGsodk6587 

CSeq: 1 INVITE 

Content-Length: 0 


F11 INVITE Proxy A -> Registrar/Authoritative Proxy B 


INVITE sip:bob@example.com SIP/2.0 

Via: SIP/2.0/TCP proxya.example.net:5060;branch=z 9hG4bKpouet 
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 
Max-Forwards: 69 

To: Bob <sip:bob@example.com> 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: lzksjf£8723k@sodk6587 

CSeq: 1 INVITE 

Record-Route: <sip:proxya.example.net;lr> 

Contact: <sip:alice@alice-1.example.net> 

Content-Type: application/sdp 

Content-Length: {as per SDP} 

{SDP not shown} 
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F12 100 (INVITE) Registrar/Authoritative Proxy B -> Proxy A 


SIP/2.0 100 Trying 

Via: SIP/2.0/TCP proxya.example.net:5060,branchez9hGibKpouet 
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 
To: Bob <sip:bob@example.com> 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: 1lzksjf£8723k@sodk6587 

CSeq: 1 INVITE 

Content-Length: 0 


F13 INVITE Registrar/Authoritative Proxy B -> Edge Proxy B 


INVITE sip:bob@bobpc.example.com SIP/2.0 

Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2 

Via: SIP/2.0/TCP proxya.example.net:5060; branch=z9hG4bKpouet 

Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 
Max-Forvards: 68 

To: Bob <sip:bob@example.com> 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: 1lzksjf£8723k@sodk6587 

CSeq: 1 INVITE 

Route: <sip:laksdyjanseg237+fsdftuy623hytIJ8@eb.example.com; lr;ob> 
Record-Route: <sip:pb.example.com;lr>, <sip:proxya.example.net;lr> 
Contact: <sip:alice@alice-1.example.net> 

Content-Type: application/sdp 

Content-Length: {as per SDP} 

{SDP not shown} 


F14’ 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B 


SIP/2.0 100 Trying 

Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2 

Via: SIP/2.0/TCP proxya.example.net:5060,branchez9hGibKpouet 

Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 
To: Bob <sip:bob@example.com> 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: 1zks3jf8723kGsodk6587 

CSeq: 1 INVITE 

Content-Length: 0 


Audet Standards Track [Page 39] 


RFC 5630 SIPS October 2009 


F15' INVITE Edge Proxy B -> Bob”s PC Client 


INVITE sip:bob@bobpc.example.com SIP/2.0 

Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKbiba 

Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2 

Via: SIP/2.0/TCP proxya.example.net:5060; branch=z9hG4bKpouet 

Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 

Max-Forvards: 67 

To: Bob <sip:bob@example.com> 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: 1zks?f8723k6sodk6587 

CSeq: 1 INVITE 

Record-Route: 
<sip:laksdyjanseg237+fsdf+uy623hyt1J8Geb.example.com;lr;ob>, 
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr> 

Contact: <sip:alice@alice-1.example.net> 

Content-Type: application/sdp 

Content-Length: {as per SDP} 

{SDP not shown} 


F16’ 180 (INVITE) Bob’s PC Client -> Edge Proxy B 


SIP/2.0 180 Ringing 

Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKbiba 

Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2 

Via: SIP/2.0/TCP proxya.example.net:5060; branch=z9hG4bKpouet 

Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 
To: Bob <sip:bobfexample.com>;tag=963258 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: 1zksjf8723kfsodk6587 

CSeq: 1 INVITE 

Record-Route: 
<sip:laksdyjanseg237+fsdf+uy623hyt1J8Geb.example.com;lr;ob>, 
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr> 

Contact: <sip:bob@bobpc.example.com> 

Content-Length: 0 
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F17' 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B 


SIP/2.0 180 Ringing 

Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2 

Via: SIP/2.0/TCP proxya.example.net:5060; branch=z9hG4bKpouet 

Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 

To: Bob <sip:bobfexample.com>;tag=963258 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: 1zks3jf8723kGsodk6587 

CSeq: 1 INVITE 

Record-Route: 
<sip:laksdyjanseg237+fsdf+uy623hyt1J8Geb.example.com;lr;ob>, 
xsip:pb.example.com,lr5, <sip:proxya.example.net;1r> 

Contact: <sip:bob@bobpc.example.com> 

Content-Length: 0 


F18’ 180 (INVITE) Registrar/Authoritative Proxy B -> Proxy A 


SIP/2.0 180 Ringing 

Via: SIP/2.0/TCP proxya.example.net:5060,branchez9hGibKpouet 

Via: SIP/2.0/TCP alice-l.example.net:5060,branchez9hGibKprout 
To: Bob <sip:bobfexample.com>;tag=963258 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: 1zks3f8723kfsodk6587 

CSeq: 1 INVITE 

Record-Route: 
<sip:laksdyjanseg237+fsdf+uy623hyt1J8Geb.example.com;lr;ob>, 
xsip:pb.example.com,lr5, <sip:proxya.example.net;1r> 

Contact: <sip:bob@bobpc.example.com> 

Content-Length: 0 
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F19' 180 (INVITE) Proxy A -> Alice 


SIP/2.0 180 Ringing 

Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 
To: Bob <sip:bobfexample.com>;tag=963258 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: 1zks3f8723kfsodk6587 

CSeq: 1 INVITE 

Record-Route: 
<sip:laksdyjanseg237+fsdf+uy623hyt1J8Geb.example.com;lr;ob>, 
<sip:pb.example.com;lr>, <sip:proxya.example.net;1r> 

Contact: <sip:bob@bobpc.example.com> 

Content-Length: 0 


F13 INVITE Registrar/Authoritative Proxy B -> Edge Proxy B 


INVITE sip:bobübobphone.example.com SIP/2.0 

Via: SIP/2.0/TCP pb.example.com:5060; branch=z9hG4bKbalouba.1 

Via: SIP/2.0/TCP proxya.example.net:5060,branchez9hGibKpouet 

Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 
Max-Forvards: 68 

To: Bob <sip:bob@example.com> 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: l1zks?f8723k6sodk6587 

CSeq: 1 INVITE 

Route: <sip:psodkfs3+34+kk1sL+uJH-Xm816k09Kkfteb.example.com;1r;ob> 
Record-Route: <sip:pb.example.com;1r>, <sip:proxya.example.net;lr> 
Contact: <sip:alice@alice-1.example.net> 

Content-Type: application/sdp 

Content-Length: (as per SDP) 

(SDP not shown) 


F14 100 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B 


SIP/2.0 100 Trying 

Via: SIP/2.0/TCP pb.example.com:5060; branch=z9hG4bKbalouba.1 

Via: SIP/2.0/TCP proxya.example.net:5060,branchez9hGibKpouet 

Via: SIP/2.0/TCP alice-l.example.net:5060,branchez9hGibKprout 
To: Bob <sip:bob@example.com> 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: l1zks?f8723k6sodk6587 

CSeq: 1 INVITE 

Content-Length: 0 
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F15 INVITE Edge Proxy B -> Bob” s Phone 


INVITE sip:bobübobphone.example.com SIP/2.0 

Via: SIP/2.0/TLS eb.example.com:5061,branchez9hGibKtroubaba 

Via: SIP/2.0/TCP pb.example.com:5060,branchez9hGibKbalouba.1 

Via: SIP/2.0/TCP proxya.example.net:5060; branch=z9hG4bKpouet 

Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 

Max-Forwards: 68 

To: Bob <sip:bob@example.com> 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: 1lzksjf£8723k@sodk6587 

CSeq: 1 INVITE 

Record-Route: 
<sip:psodkfsj+34+kk1sL+uJH-Xm816k09Kk@eb.example.com;1r;ob>, 
xsip:pb.example.com,lr5, <sip:proxya.example.net;lr> 

Contact: <sip:alice@alice-1.example.net> 

Content-Type: application/sdp 

Content-Length: {as per SDP} 

{SDP not shown} 


F16 180 (INVITE) Bob’s Phone -> Edge Proxy B 


SIP/2.0 180 Ringing 

Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba 

Via: SIP/2.0/TCP pb.example.com:5060,branchez9hGi4bKbalouba.1 

Via: SIP/2.0/TCP proxya.example.net:5060,branchez9hGibKpouet 

Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 
To: Bob <sip:bobfexample.com>;tag=5551212 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: 1zks3f8723kfsodk6587 

CSeq: 1 INVITE 

Record-Route: 
<sip:psodkfs3+34+kk1sL+uJH-*Xm816k09Kkfteb.example.com;l1r;ob>, 
xsip:pb.example.com,lr5, <sip:proxya.example.net;1r> 

Contact: <sip:bob@bobphone.example.com> 

Content-Length: 0 
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F17 180 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B 


SIP/2.0 180 Ringing 

Via: SIP/2.0/TCP pb.example.com:5060,branchez9hGibKbalouba.1 

Via: SIP/2.0/TCP proxya.example.net:5060; branch=z9hG4bKpouet 

Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 

To: Bob <sip:bobfexample.com>;tag=5551212 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: 1zks3f8723kfsodk6587 

CSeq: 1 INVITE 

Record-Route: 
<sip:psodkfsj+34+kk1sL+uJH-Xm816k09Kk@eb.example.com;1r;ob>, 
<sip:pb.example.com;lr>, <sip:proxya.example.net;1r> 

Contact: <sip:bob@bobphone.example.com> 

Content-Length: 0 


F18 180 (INVITE) Registrar/Authoritative Proxy B -> Proxy A 


SIP/2.0 180 Ringing 

Via: SIP/2.0/TCP proxya.example.net:5060; branch=z9hG4bKpouet 

Via: SIP/2.0/TCP alice-l.example.net:5060,branchez9hGibKprout 
To: Bob <sip:bobfexample.com>;tag=5551212 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: 1zks3f8723kfsodk6587 

CSeq: 1 INVITE 

Record-Route: 
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;1lr;ob>, 
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr> 

Contact: <sip:bob@bobphone.example.com> 

Content-Length: 0 
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F19 180 (INVITE) Proxy A -> Alice 


SIP/2.0 180 Ringing 

Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 

To: Bob <sip:bobfexample.com>;tag=5551212 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: 1zks3f8723kfsodk6587 

CSeq: 1 INVITE 

Record-Route: 
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;1lr;ob>, 
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr> 

Contact: <sip:bob@bobphone.example.com> 

Content-Length: 0 


F20 200 (INVITE) Bob’s Phone -> Edge Proxy B 


SIP/2.0 200 OK 

Via: SIP/2.0/TLS eb.example.com:5061,branchez9hGibKtroubaba 

Via: SIP/2.0/TCP pb.example.com:5060,branchez9hG4bKbalouba.1 

Via: SIP/2.0/TCP proxya.example.net:5060; branch=z9hG4bKpouet 

Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 
To: Bob <sip:bobfexample.com>;tag=5551212 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: 1zks3f8723kfsodk6587 

CSeq: 1 INVITE 

Record-Route: 
<sip:psodkfsj+34+kk1lsL+uJH-Xm816k09Kk@eb.example.com;1lr;ob>, 
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr> 
Contact: <sip:bob@bobphone.example.com> 

Content-Length: 0 
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F21 200 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B 


SIP/2.0 200 OK 

Via: SIP/2.0/TCP pb.example.com:5060,branchez9hGi4bKbalouba.1 

Via: SIP/2.0/TCP proxya.example.net:5060,branchez9hGibKpouet 

Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 

To: Bob <sip:bobfexample.com>;tag=5551212 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: 1zks3f8723kfsodk6587 

CSeq: 1 INVITE 

Record-Route: 
<sip:psodkfsj+34+kk1sL+uJH-Xm816k09Kk@eb.example.com;1r;ob>, 
<sip:pb.example.com;lr>, <sip:proxya.example.net;1r> 

Contact: <sip:bob@bobphone.example.com> 

Content-Length: 0 


F22 200 (INVITE) Registrar/Authoritative Proxy B -> Proxy A 


SIP/2.0 200 OK 

Via: SIP/2.0/TCP proxya.example.net:5060; branch=z9hG4bKpouet 

Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 
To: Bob <sip:bobfexample.com>;tag=5551212 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: 1zks3f8723kfsodk6587 

CSeq: 1 INVITE 

Record-Route: 
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;1lr;ob>, 
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr> 

Contact: <sip:bob@bobphone.example.com> 

Content-Length: 0 
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F23 200 (INVITE) Proxy A -> Alice 


SIP/2.0 200 OK 

Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 
To: Bob <sip:bobfexample.com>;tag=5551212 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: 1zks3f8723kfsodk6587 

CSeq: 1 INVITE 

Record-Route: 
<sip:psodkfsj+34+kklsL+uJH-Xm816k09Kk@eb.example.com;1lr;ob>, 
<sip:pb.example.com;lr>, <sip:proxya.example.net;lr> 

Contact: <sip:bob@bobphone.example.com> 

Content-Length: 0 


F24 ACK Alice -> Proxy A 


ACK sip:bob@bobphone.example.com SIP/2.0 

Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 

Max-Forvards: 70 

To: Bob <sip:bobfexample.com>;tag=5551212 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: 1zks3f8723kfsodk6587 

CSeq: 1 ACK 

Route: <sip:proxya.example.net;lr>, <sip:pb.example.com;1r>, 
<sip:psodkfsj+34+kk1lsL+uJH-Xm816k09Kk@edge.example.com; lr; ob> 

Content-Length: 0 


F25 ACK Proxy A -> Registrar/Authoritative Proxy B 


ACK sip:bobübobphone.example.com SIP/2.0 

Via: SIP/2.0/TCP proxya.example.net:5060; branch=z9hG4bKpouet 

Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 

Max-Forvards: 69 

To: Bob <sip:bobfexample.com>;tag=5551212 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: l1zks?f8723k6sodk6587 

CSeq: 1 ACK 

Route: <sip:pb.example.com;1r>, 

<sip:psodkfsj+34+kk1sL+uJH-Xm816k09Kk@eb.example.com; 1r, ob> 

Content-Length: 0 
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F26 ACK Registrar/Authoritative Proxy B -5 Edge Proxy B 


ACK sip:bobübobphone.example.com SIP/2.0 

Via: SIP/2.0/TCP pb.example.com:5060,branchez9hGi4bKbalouba.1 
Via: SIP/2.0/TCP proxya.example.net:5060; branch=z9hG4bKpouet 
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 
Max-Forvards: 69 

To: Bob <sip:bobfexample.com>;tag=5551212 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: l1zks?f8723k6sodk6587 

CSeq: 1 ACK 

Route: <sip:psodkfsj+34+kkl1sL+uJH-Xm816k09KkGeb.example.com; lY: ob> 
Content-Length: 0 


F27 ACK Proxy B -> Bob”s Phone 


ACK sip:bobübobphone.example.com SIP/2.0 

Via: SIP/2.0/TLS eb.example.com:5061;branch=z9hG4bKtroubaba 
Via: SIP/2.0/TCP pb.example.com:5060,branchez9hGi4bKbalouba.1 
Via: SIP/2.0/TCP proxya.example.net:5060,branchez9hGibKpouet 
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 
Max-Forvards: 68 

To: Bob <sip:bobfexample.com>;tag=5551212 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: l1zks?f8723k6sodk6587 

CSeq: 1 ACK 

Content-Length: 0 


F26’ CANCEL Registrar/Authoritative Proxy B -> Edge Proxy B 


CANCEL sip:bob@bobpc.example.com SIP/2.0 

Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2 
Max-Forvards: 70 

To: Bob <sip:bob@example.com> 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: 1lzksjf£8723k@sodk6587 

CSeq: 1 CANCEL 

Route: <sip:psodkfs3+34+kk1sL+uJH-Xm816k09Kkfteb.example.com;1r;ob> 
Content-Length: 0 
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F27' CANCEL Edge Proxy B -> Bob's PC Client 


CANCEL sip:bob@bobpc.example.com SIP/2.0 

Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba 
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2 
Max-Forvards: 69 

To: Bob <sip:bob@example.com> 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: l1zks?f8723k6sodk6587 

CSeq: 1 CANCEL 

Content-Length: 0 


F28' 200 (CANCEL) Bob's PC Client -> Edge Proxy B 


SIP/2.0 200 OK 

Via: SIP/2.0/TCP eb.example.com:5060,branchez9hGibKtroubaba 
Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2 
To: Bob <sip:bob@example.com> 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: l1zks?f8723k6sodk6587 

CSeq: 1 CANCEL 

Content-Length: 0 


F29' 200 (CANCEL) Edge Proxy B -> Registrar/Authoritative Proxy B 


SIP/2.0 200 OK 

Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2 
To: Bob <sip:bob@example.com> 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: 1zks3jf8723kGsodk6587 

CSeq: 1 CANCEL 

Content-Length: 0 


Audet Standards Track [Page 491 


RFC 5630 SIPS October 2009 


F30’ 487 (INVITE) Bob's PC Client -> Edge Proxy B 


SIP/2.0 487 Request Terminated 

Via: SIP/2.0/TCP eb.example.com:5060;branch=z9hG4bKtroubaba 
Via: SIP/2.0/TCP pb.example.com:5060,branchez9hG4bKbalouba.2 
Via: SIP/2.0/TCP proxya.example.net:5060; branch=z9hG4bKpouet 
Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 
To: Bob <sip:bob@example.com> 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: l1zks?f8723k6sodk6587 

CSeq: 1 INVITE 

Content-Length: 0 


F31’ 487 (INVITE) Edge Proxy B -> Registrar/Authoritative Proxy B 


SIP/2.0 487 Request Terminated 

Via: SIP/2.0/TCP pb.example.com:5060;branch=z9hG4bKbalouba.2 

Via: SIP/2.0/TCP proxya.example.net:5060;branch=z 9hG4bKpouet 

Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout 
To: Bob <sip:bob@example.com> 

From: Alice <sip:alice@example.net>;tag=8675309 

Call-ID: 1zks3jf8723kGsodk6587 

CSeq: 1 INVITE 

Content-Length: 0 


6.4. Alice Calls Bob’s SIP AOR Using TLS 
Bob’s registration has already occurred as per Section 6.1. 


The third example is identical to the second one, except that Alice 
uses TLS as the transport for her connection to her proxy. Such an 
arrangement would be common if Alice’s UA supported TLS and wanted to 
use a single connection to the proxy (as would be the case when using 
[RFC5626]). In the example below, Proxy A is also using TLS as a 
transport to communicate with Outbound Proxy B, but it is not 
necessarily the case. 


When using a SIP URI in the Request-URI but TLS as a transport for 
sending the request, the Via field indicates TLS. The Route header 
field (if present) typically would use a SIP URI (but it could also 
be a SIPS URI). The Contact header fields and To and From, however 
would also normally indicate a SIP URI. 


The call flow would be exactly as per the second example 

(Section 6.3). The only difference would be that all the Via header 
fields would use TLS Via parameters. The URIS would remain SIP URIs 
and not SIPS URIs. 
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7. 


Further Considerations 


SIP (RFC32611 itself introduces some complications vith using SIPS, 
for example, when Record-Route is not used. When a SIPS URI is used 
in a Contact header field in a dialog-initiating request and Record- 
Route is not used, that SIPS URI might not be usable by the other 
end. If the other end does not support SIPS and/or TLS, it will not 
be able to use it. The last-hop exception is an example of vhen this 
can occur. In this case, using Record-Route so that the requests are 
sent through proxies can help in making it work. Another example is 
that even in a case vhere the Contact header field is a SIPS URI, no 
Record-Route is used, and the far end supports SIPS and TLS, it might 
still not be possible for the far end to establish a TLS connection 
vith the SIP originating end if the certificate cannot be validated 
by the far end. This could typically be the case if the originating 
end vas using server-side authentication as described belov, or if 
the originating end is not using a certificate that can be validated. 


TLS itself has a significant impact on hov SIPS can be used. Server- 
side authentication (where the server side provides its certificate 
but the client side does not) is typically used betveen a SIP end- 
user device acting as the TLS client side (e.g., a phone or a 
personal computer) and its SIP server (proxy or registrar) acting as 
the TLS server side. TLS mutual authentication (where both the 
client side and the server side provide their respective 
certificates) is typically used betveen SIP servers (proxies, 
registrars), or statically configured devices such as PSTN gatevays 
or media servers. In the mutual authentication model, for two 
entities to be able to establish a TLS connection, it is required 
that both sides be able to validate each other”s certificates, either 
by static configuration or by being able to recurse to a valid root 
certificate. With server-side authentication, only the client side 
is capable of validating the server side”s certificate, as the client 
side does not provide a certificate. The consequences of all this 
are that vhenever a SIPS URI is used to establish a TLS connection, 
it is expected to be possible for the entity establishing the 
connection (the client) to validate the certificate from the server 
side. For server-side authentication, İRFC56261 is the recommended 
approach. For mutual authentication, one needs to ensure that the 
architecture of the netvork is such that connections are made betveen 
entities that have access to each other's certificates.  Record-Route 
İRFC32611 and Path [RFC3327] are very useful in ensuring that 
previously established TLS connections can be reused. Other 
mechanisms might also be used in certain circumstances: for example, 
using root certificates that are videly recognized allovs for more 
easily created TLS connections. 
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8. 


10. 


Security Considerations 


Most of this document can be considered to be security considerations 
since it applies to the usage of the SIPS URI. 


The "last-hop exception" of [RFC3261] introduced significant 
potential vulnerabilities in SIP, and it has therefore been 
deprecated by this specification. 


Section 26.4.4 of [RFC3261] describes the security considerations for 
the SIPS URI scheme. These security considerations also applies 
here, as modified by Appendix A. 


IANA Considerations 


This specification registers two new warning codes, namely, 380 "SIPS 
Not Alloved" and 381 "SIPS Required". The varning codes are defined 
as follows, and have been included in the Warning Codes (warn-codes) 

sub-registry of the SIP Parameters registry available from 

http: //www.iana.org. 


380 SIPS Not Allowed: The UAS or proxy cannot process the request 
because the SIPS scheme is not allowed (e.g., because there are 
currently no registered SIPS contacts). 


381 SIPS Required: The UAS or proxy cannot process the request 
because the SIPS scheme is required. 


Reference: RFC 5630 
The note in the Warning Codes sub-registry is as follows: 


Warning codes provide information supplemental to the status code 
in SIP response messages. 
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Appendix A. Bug Fixes for RFC 3261 


In order to support the material in this document, this section makes 
corrections to RFC 3261. 


The last sentence of the fifth paragraph of Section 8.1.3.5 is 
replaced by: 


The client SHOULD retry the request, this time, using a SIP URI 
unless the original Request-URI used a SIPS scheme, in vhich case 
the client MUST NOT retry the request automatically. 


The fifth paragraph of Section 10.2.1 is replaced by: 


If the Address of Record in the To header field of a REGISTER 
request is a SIPS URI, then the UAC MUST also include only SIPS 
URIs in any Contact header field value in the requests. 


In Section 16.7 on p. 112 describing Record-Route, the second 
paragraph is deleted. 


The last paragraph of Section 19.1 is reworded as follows: 


A SIPS URI specifies that the resource be contacted securely. 

This means, in particular, that TLS is to be used on each hop 

betveen the UAC and the resource identified by the target SIPS 
URI. Any resources described by a SIP URI (...) 


In the third paragraph of Section 20.43, the words "the session 
description" in the first sentence are replaced with "SIP". Later in 
the paragraph, "390" is replaced with "380", and "miscellaneous 
varnings" is replaced vith "miscellaneous SIP-related varnings". 


The second paragraph of Section 26.2.2 is revorded as follows: 


(...) When used as the Request-URI of a request, the SIPS scheme 
signifies that each hop over which the request is forwarded, until 
the request reaches the resource identified by the Request-URI, is 
secured with TLS. When used by the originator of a request (as 
vould be the case if they employed a SIPS URI as the address-of- 
record of the target), SIPS dictates that the entire request path 
to the target domain be so secured. 


The first paragraph of Section 26.4.4 is replaced by the following: 
Actually using TLS on every segment of a request path entails that 


the terminating UAS is reachable over TLS (by registering with a 
SIPS URI as a contact address). The SIPS scheme implies 
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transitive trust. Obviously, there is nothing that prevents 
proxies from cheating. Thus, SIPS cannot guarantee that TLS usage 
vill be truly respected end-to-end on each segment of a request 
path. Note that since many UAs will not accept incoming TLS 
connections, even those UAs that do support TLS vill be required 
to maintain persistent TLS connections as described in the TLS 
limitations section above in order to receive requests over TLS as 
a UAS. 


The first sentence of the third paragraph of Section 26.4.4 is 
replaced by the folloving: 


Ensuring that TLS vill be used for all of the request segments up 
to the target UAS is somevhat complex. 


The fourth paragraph of Section 26.4.4 is deleted. 


The last sentence of the fifth paragraph of Section 26.4.4 is 
revorded as follovs: 


S/MIME or, preferably, [RFC4474] may also be used by the 
originating UAC to help ensure that the original form of the To 
header field is carried end-to-end. 
In the third paragraph of Section 27.2, the phrase "when the failure 
of the transaction results from a Session Description Protocol (SDP) 
(RFC 2327 (11) problem" is deleted. 
In the fifth paragraph of Section 27.2, "390" is replaced with "380", 
and "miscellaneous warnings" is replaced with "miscellaneous SIP- 
related warnings". 
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